[RFC] feat(linux): s2idle: Document the mode selection logic#641
[RFC] feat(linux): s2idle: Document the mode selection logic#641DhruvaG2000 wants to merge 1 commit intoTexasInstruments:masterfrom
Conversation
kwillis01
left a comment
There was a problem hiding this comment.
It might be good to see if there are other places in the previous parts of the doc that can be updated or that the new info can loop into and consolidate.
995b85e to
6209735
Compare
kwillis01
left a comment
There was a problem hiding this comment.
Mostly looks good, I think that the QoS Latency Constraints and Mode Selection section needs to be fixed up to flow better and be a little more condensed.
|
|
||
| **Setting QoS Constraints from User Space:** | ||
|
|
||
| Applications can constrain the system's low-power behavior by writing to the PM QoS device file. |
There was a problem hiding this comment.
I think it should be specified that it is the PM QoS CPU wakeup latency file. Just because this sentence makes it sound like each device would have a PM QoS file, when its only for CPUs.
| 3. Only idle states with ``exit-latency-us`` ≤ constraint are considered | ||
| 4. The deepest eligible state is selected | ||
|
|
||
| **Setting QoS Constraints from User Space:** |
There was a problem hiding this comment.
I think this section should be combined with the Example: Deep Sleep Mode Selection section. You're showing an example of how to set the QoS constraint without properly explaining it. Also by combining with the Example: Deep Sleep Mode Selection section you can make this into an example for just deepsleep
| that the cpuidle governor correctly respects QoS constraints and selects the appropriate idle state | ||
| based on latency requirements. | ||
|
|
||
| **Selecting Specific Low-Power Modes:** |
There was a problem hiding this comment.
This section should go after the How It Sets QoS Constraints: section since that is when the /dev/cpu_wakeup_latency is explained
|
Additionally, could you update the RTC + DDR section in |
Document the mode selection logic using the s2idle flow Signed-off-by: Dhruva Gole <d-gole@ti.com>
6209735 to
8532d2e
Compare
|
New warnings found with rstcheck: |
| .. note:: | ||
| For complete Device Tree definitions including all latency parameters, refer to the platform's | ||
| device tree source files (e.g., ``k3-am62l3-evm-idle-states.dtso``). |
There was a problem hiding this comment.
| .. note:: | |
| For complete Device Tree definitions including all latency parameters, refer to the platform's | |
| device tree source files (e.g., ``k3-am62l3-evm-idle-states.dtso``). | |
| .. note:: | |
| For complete Device Tree definitions including all latency parameters, refer to the platform's | |
| device tree source files (e.g., ``k3-am62l3-evm-idle-states.dtso``). |
|
|
||
| .. code-block:: bash | ||
|
|
||
| exec 4<>/dev/cpu_wakeup_latency; echo 0x3e8 >&4 |
There was a problem hiding this comment.
This seems a little convoluted for what could just be
| exec 4<>/dev/cpu_wakeup_latency; echo 0x3e8 >&4 | |
| echo 0x3e8 | tee /dev/cpu_wakeup_latency |
or
| exec 4<>/dev/cpu_wakeup_latency; echo 0x3e8 >&4 | |
| echo 0x3e8 > /dev/cpu_wakeup_latency |
Like I know that exec line is a more literal interpretation of the above c example, but if someone's doing it through bash then they probably don't really understand those redirects.
| printf("QoS set to %s. Press Ctrl+C to exit.\n", LATENCY_VAL); | ||
|
|
||
| while (keep_running) | ||
| sleep(1); | ||
|
|
||
| close(fd); | ||
| printf("Released.\n"); | ||
| return 0; |
There was a problem hiding this comment.
Why are we holding this process open with an aggressive loop? There's nothing in the kernel docs that says the value is dropped when the FD is released.
Document the mode selection logic using the s2idle flow